1. Technical Field
This invention relates generally to executing a section of code on an all-or-nothing basis, such that the entire section of code is executed and committed to memory, or none of the section of code is executed and committed to memory. The invention relates more particularly to software locking approaches and hardware transactional approaches to such execution of code on an all-or-nothing basis.
2. Description of the Prior Art
In multiple-processor computing systems, more than one processor may attempt to affect the same memory at the same time. For instance, a number of transactions, which may be read or write requests or responses to resources such as memory, may vie for the same memory at the same time. If each transaction is allowed unfettered access to the same memory, the results can include corrupting the integrity of the data stored in this memory. For example, one transaction may read a given memory line, act upon the value read, and then write a new value to the memory line. While the transaction is acting upon the value it read from the memory line, another transaction may write a different value to the memory line. When the first transaction writes its new value to the memory line, the second transaction may not realize that its value has been overwritten.
One approach to ensuring that a number of transactions are not attempting to process the same memory at the same time is to use a software locking approach. In a software locking approach, a transaction must first successfully obtain a lock on the relevant lines of memory before it is able to process the data stored in these memory lines. If two transactions are attempting to process the same memory line, then one transaction will initially win the lock, and be able to process the memory line before the second transaction does. Thus, the transactions are implicitly serialized, so that they do not try to compete for the same memory line at the same time. A disadvantage to using the software locking approach is that it can add overhead to the processing of transactions that in most cases is unnecessary, since most of the time there will be no contention for desired memory lines. This can cause degradation in performance of the entire system.
Another approach to ensuring that a number of transactions are not attempting to process the same memory at the same time is to use a hardware transactional memory approach. In a hardware transactional memory approach, the hardware of a system, specifically its processors, have the ability to process sections of code as transactional memory. Transactional memory can thus be considered as a way to bracket a code section such that it becomes a large, multi-argument load link/store conditional (LL/SC) transaction. The code section is executed speculatively, and the decision to commit the changes is deferred until the end of the section of code. If there has been any interference with any of the data used by the code section, such as the memory lines, cache lines, and so on, being used by the code section, then the entire transaction is aborted. Otherwise, the entire transaction is committed to memory, and the changes memory to the relevant memory and caches lines are effected.
While the hardware transactional memory approach is faster in performance than the software locking approach, it nevertheless suffers from some disadvantages. For the hardware transactional memory approach to work, the operations performed by the relevant section of code are accomplished within a cache before being committed to memory. However, if the cache is not large enough, or does not have great enough associativity, then the approach will fail. This is because the entire section of code will not be able to be completely executed speculatively before the processing effects of the code section are committed to memory. That is, the hardware transactional memory approach, while advantageous in performance as compared to the software locking approach, is not as widespread in its potential application as is the software locking approach. For these and other reasons, therefore, there is a need for the present invention.